home *** CD-ROM | disk | FTP | other *** search
- Date: Tue, 31 May 1994 13:34:47 -0400 (EDT)
- From: Timothy Miller <millert@undergrad.csee.usf.edu>
- Subject: Re: Colour.
- To: gem-list@world.std.com
- In-Reply-To: <199405310906.LAA06920@blade.stack.urc.tue.nl>
- Message-Id: <Pine.3.87.9405311347.A24625-0100000@undergrad>
- Mime-Version: 1.0
- Precedence: bulk
-
-
-
- On Tue, 31 May 1994, Erlend Nagel wrote:
-
- > I wrote:
- >
- > > > But a program could do a request for a colour within a certain margin
- > > > from some value.
- >
- > Timothy wrote:
- >
- > > No. An app should be able to get EXACTLY what color it asks for.
- >
- > I probably was a bit unclear. The way I saw it, a program sends a
- > request for colour X with margin 0 and then it should get EXACTLY that
- > colour. Nice uh?
- >
- > Erlend.
- >
- Quite, but I think me may be deviating slightly. The manager is going to
- have to manage many palettes, one for each window, and it may not matter
- what's in the palette.
-
- I suppose the manager might have facilities for helping the app to build
- a palette that is as close as possible to the current one, but if an app
- doesn't follow our standard, the manager's going to have to handle the
- palette changes automatically anyway.
-
- Some apps (like GEMview) change the palette when topping a window, but
- this shouldn't conflict with our manager as long as the manager is able
- to record the palette belonging to a GEMview window just before it's
- untopped, so that when the window is topped, GEMview and the manager both
- set the same palette.
-
- The problem is catching the system JUST before a misbehaved app sets the
- palette of its newly topped window so the palette for the untopped window
- can be recorded. Is WM_UNTOPPED broadcast globally? Is it broadcast
- BEFORE WM_TOPPED? If so, then there is no problem.
-
-
-